Skip to main content

Secure Software Development Lifecycle (SSDLC)

Context: CIVITAS/CORE is delivered as software only. We do not operate any production instances. All runtime security and operational controls are the responsibility of each deploying organization (“user-operators”). Our SSDLC focuses on shipping a secure-by-default product, transparent supply chain, and high‑quality security documentation for safe operation.

For developers, we offer a Secure Development Guide that will be more helpful day-to-day. This document covers the policy part of the system: what standards we adhere to, and how we mark out our security posture. It is primarily aimed at DPOs, auditors, and similarly interested parties.

1. Scope & Objectives​

  • In scope: source code, build & release processes, documentation, example configs/manifests, sample data, CI/CD, dependency management, vulnerability handling, security communications, network configuration, logging capabilities.
  • Out of scope: hosting, data residency, backups/DR retention and hosting, monitoring/alerting, incident response for user-operated deployments, logging configuration.
  • Goals:
    • Ensure a TR-03187-compliant solution for users (see also section 14.2).
    • Minimize vulnerabilities at design and implementation time.
    • Ensure default configuration is secure.
    • Make builds reproducible, auditable, and verifiable.
    • Provide clear, actionable hardening and operations guidance to user-operators.
    • Respond quickly and transparently to reported issues.
    • Respond quickly to issues in upstream components.

2. Assumptions & Data Handling​

  • Assumptions

    • Deployments run in user-operator environments (on‑prem or cloud). This means that the platform is deployed and hosted by the customers themselves, and they are the primary custodian of the running environment.
    • External integrations (e.g., IdP, databases, message buses) are provided and secured by user-operators.
    • Application is distributed as Helm Charts, Helmfile, and Container Images, i.e. infrastructure configuration is in-scope (above the k8s level)

  • Data

    • CIVITAS/CORE processes user-provided domain data. No Personally Identifiable Information (PII) leaves the user environment unless explicitly enabled by the user-operator.
    • We guard all optional reporting and data handling behind clear configuration flags.
    • Data handling follows minimal TR-03187 expectations for Data Governance level I.
    • Logical multi-tenancy is supported; we document how to configure tenant isolation (e.g. per-tenant realms, projects, or namespaces) and the consequences for data mapping and access control.

3. Roles & Responsibilities (build-time vs. run-time)​

In this table, we define responsibilities and roles (RACI-ish) that span the CIVITAS/CORE team and the user-operator, and aim to separate which parts of those shared responsilities lie with whom.

AreaCIVITAS/CORE team (build-time)User-operator (run-time)
Threat modelingCreate & maintain product-level model; publish assumptionsValidate against local deployment & integrations
Identity & authSupport standards (OIDC/OAuth2); secure defaultsConfigure IdP, policies, secrets rotation
SecretsNo secrets hard-coded; local .env.sampleProvision, store, rotate, and scope secrets
HardeningProvide baseline hardening guide & defaultsApply/verify hardening in their infra
LoggingStructured logs, log levels documented, ensure log anonymizationCentralize, retain, monitor, alert
UpdatesSigned releases, advisories, migration guidesPatch management & rollout
Incident responseCoordinate disclosure process (non-ops)Full IR/forensics in their environment

4. Security Standards & References​

We primarily operate our security posture under the guidance of these standards and guiding principles:

  • TR-03187: Requirements applicable to Entwickler and Lösungsanbieter for urbane Datenplattformen, Schutzlevel 1+ (Architektur, Auth/Autz, Schnittstellen, Logging, Datenhaltung, IT-Sicherheitsorganisation).
  • IT-Grundschutz: Operator-facing, but we ensure that our product and docs can be integrated into an IT-Grundschutz/ISO based ISMS (e.g. clear assets, data flows, and security controls).
  • Development: Language-specific secure coding guidelines (derived from OWASP ASVS L2+ and BSI best practices) are mandatory for contributors.
  • Supply Chain: SBOM (CycloneDX), dependency pinning + vulnerability scanning, signed artifacts (Sigstore/Cosign), provenance (SLSA-aligned). Managed by CI.
  • Cryptography: Only platform/standard libraries; modern TLS by default; no homegrown cryptography. Algorithms and key lengths as per BSI TR-02102.
  • Privacy: Data minimization and purpose limitation; operators receive guidance on configuration choices with privacy impact (e.g. logging and retention).

5. Threat Model (summary)​

  • Assets: configuration secrets, service tokens, data at rest/in transit, admin interfaces, update channels.

Further reading:

6. SSDLC Phases & Required Activities​

6.1 Governance (continuous)​

  • The security owner role is split between responsibility (lies with the security team) and accountability (lies with the product owner). Responsible for SSDLC, risk decisions on the developer/vendor side, and TR-03187 mapping.
  • Policies (documented and versioned):
    • Secure coding standards per language.
    • Dependency and third-party components policy (incl. allowed license types).
    • Secret handling (no secrets in repo/images; required storage mechanisms).
    • Code review policy (required reviewers, when security review is mandatory).
    • Release policy (signing, SBOM, provenance, supported versions).
  • Checkpoints:
    • Security sign-off required for High sensitivity changes (see 14.1) and changes affecting TR-03187 building blocks (Architektur, Auth/Autz, Schnittstellen, Logging, Datenhaltung).
    • Risk acceptance is recorded (who, when, rationale, expiry/reevaluation date).
  • Competence / Training:
    • Onboarding checklist includes secure-coding and SSDLC intro.
  • Internal auditing:
    • At least annually, we sample releases and verify that SSDLC controls (this document) are actually applied (threat models exist, security tests run, SBOMs published, etc.).
    • Findings are tracked as tickets and fed into the security backlog.

6.2 Requirements​

  • Capture security/abuse cases with each feature, based on documented threat landscape.
  • Define authN/AuthZ requirements, data classification, and external trust boundaries.
  • Document operator‑visible settings (flags, env vars, RBAC).
  • To what extent do BSI TR-03187 requirements for architecture, organistion, web, etc. pertain to feature and how are they ensured? Also check Secure Coding Guide.
  • Ensure that architectural security properties are not violated
  • For each feature or change, assess which TR-03187 building blocks are affected (Architektur, Auth/Autz, Schnittstellen, Logging, Datenhaltung, Organisation) and record resulting requirements or constraints in the Security Requirements Note (SRN).

Artifact: Security Requirements Note (SRN) linked to the ticket. TODO: should this be its own doc or added to issue/MR?*

6.3 Design​

  • Lightweight threat modeling (e.g. STRIDE, attack path analysis) for new components/integrations.
  • Select protocols/crypto from approved list (based on BSI TR-02102); choose “secure by default” configs and document rationale/trade offs
  • Ensure the following "secure by design" principles are considered: Principle of least privilege (principals only get privileges needed to fulfil documented purpose), fail to secure state (e.g. deny access when error occurs while permission calculation), complete mediation (check access privileges on each access), attack surface minimization (disable unused ports/services/features), sandboxing (when executing non-trustworthy code)
  • When security debt is made, document risk acceptance (e.g. "Full attack surface minimization conflicts with shipping goals -> Ticket created to implement full attack surface minimization") in risk board.
  • Plan observability (what to log, redaction).

Artifact: Optional design document + threat model delta.

6.4 Implementation​

  • Enforce non‑bypassable authZ checks at service boundaries.

  • Follow the Secure Coding Guide, as well as the topic-specific guidelines.

  • Input validation & output encoding; parameterized queries; safe file & path handling.

  • Feature flags default to safest mode (least privilege, minimal exposure).

  • All externally reachable interfaces (HTTP APIs, message queues, webhooks, admin UIs) MUST:

    • implement input validation and authentication at the first entry point,
    • support disabling or restricting unused endpoints/features via configuration,
    • document rate-limiting and abuse-prevention options for operators.

  • Tooling (mandatory):

    • SAST & linters in CI (blocking severity threshold).
    • Dependency scanning on lockfiles.
    • Secret scanning (pre‑commit + CI).
    • License policy checks.

Artifact: Passing CI security pipeline.

6.5 Verification & Test​

  • Unit tests for security controls (RBAC, validation).
  • Integration tests for auth flows and error paths.
  • Dependency diff review at release cut.
  • Manual security review for high‑risk features.
  • For major releases, perform a checklist-based review against the TR-03187 developer/vendor requirements for the targeted Schutzlevel and record any gaps as security backlog items.

Artifact: Security Test Report (STR) + coverage metrics.

6.6 Release & Supply Chain​

  • Generate SBOM (CycloneDX) and attach to release.
  • Build in clean CI with hermetic/reproducible steps where feasible.
  • Sign all artifacts (containers, archives) and publish verification steps.
  • Make a reasonable effort to minimize shipped dependencies, at least for first level dependencies. This also goes for binaries, if applicable.
  • Do not ship any debugging tools to production, even if not publically accessible.
  • Write operator‑first Release Notes, Migration Guide, and Breaking Changes callouts.

Artifacts: Signed binaries/images, SBOM, provenance, notes.

6.7 Deployment Guidance (for user-operators)​

  • Ship an Ops Hardening Guide including:
    • Network policy (ingress/egress), TLS, headers, CSP.
    • IdP integration (OIDC) with recommended defaults (session policy, MFA).
    • Secret storage (KMS/SealedSecrets), rotation intervals.
    • Baseline dashboards and alerts (metrics & log queries).
  • Provide reference manifests (Docker Compose, Helm) hardened by default (non‑root, read‑only FS, seccomp, minimal caps, resource limits).
  • Provide CIS‑style checklists for Kubernetes and Linux hosts.

6.8 Maintenance​

  • Dependencies are checked automatically on CI/CD run for frontend, backend, and container images, and are blocked if vulnerable versions are found. Check the security policies repository as well as the CI definitions for a machine and human readable source of truth.
  • Regular dependency refresh cadence: every three sprints, the security team proactively checks dependency versions.
    • A dependabot workflow will be put in place.
  • Quarterly security backlog triage; aging policy for exceptions.
  • Retire deprecated APIs with timeline and warnings.

7. Vulnerability Intake & Disclosure​

We follow the approach defined in Reporting Vulnerabilities.

8. Logging and Privacy​

  • Logging capabilities (developer responsibilities):
    • Structured logs with clear event IDs; sensitive fields redacted by default.
    • Log key security-relevant events (at minimum):
      • authentication attempts (success/failure, including admin logins),
      • authorization failures,
      • configuration and policy changes,
      • changes to identities, roles, and permissions,
      • lifecycle events of integration connectors (start/stop/error),
      • update/upgrade of components and plugins.
    • Log records include timestamp, component, correlation ID/trace ID, and origin (user/service ID where applicable).
    • Logging is designed so that operators can forward it to SIEM and implement TR-03187 logging/monitoring requirements; we document recommended log categories and example queries.
  • Log protection (shared):
    • Application components never write logs to world-writable locations and avoid mixing tenant data in log entries where not required.
    • Integrity, retention, and access control for log storage are operator responsibilities; the hardening guide spells out minimum expectations (e.g. time synchronization, write-once or append-only storage, access restrictions).

9. Configuration & Defaults (operator-facing)​

  • Defaults:
    • Admin endpoint bound to localhost unless explicitly exposed.
    • HTTPS required when tokens/cookies are enabled.
    • Secure cookies; short‑lived tokens; refresh flow documented.
    • CSP, HSTS, anti‑XSS headers on by default in reference gateways.
    • Admin passwords need to be individualized e.g. during installation. No default passwords.
    • All storage backends are expected to support encryption at rest; operator docs explicitly call this out and list supported configurations (e.g. DB-level TDE, encrypted volumes).
    • Secrets are never persisted unencrypted by the application; we always use the platform’s secret store abstractions (Kubernetes Secrets, KMS, SealedSecrets, etc.) and document recommended configurations.
  • Tuning:
    • RBAC roles with least‑privilege presets; custom roles supported.
    • Rate limits & audit retention are configurable; safe presets provided.

10. Quality Gates (go/no‑go)​

A release must meet:

  • CI green, including SAST, dependency scan, secret scan, license checks.
  • SBOM generated; no known Criticals in runtime deps (documented exceptions only).
  • Threat model updated for changed boundaries.
  • Release artifacts signed; verification instructions tested.
  • Ops docs reviewed by an engineer not authoring the feature.

11. Checklists​

11.1 Pull Request (developer)​

  • Sensitivity noted (Low / Medium / High) in the PR.
  • SRN updated/linked with threats/abuse cases, AuthN/AuthZ expectations, data considerations.
  • All new endpoints/commands/jobs define authentication, authorization, input validation, and security-relevant logging.
  • No secrets or credentials introduced.
  • New configuration/flags documented with secure defaults.
  • Tests updated (happy-path + at least one security-relevant failure/edge case per abuse case).
  • CI is green (SAST/linters, dependency scan, secret scan, license checks).
  • For High sensitivity: security reviewer/rotation tagged and any intentional security debt documented.

11.2 Pre‑Release (maintainer)​

  • SBOM generated by CI and attached to the release.
  • Images/binaries are signed; verification steps exercised at least once.
  • Dependency diff reviewed; Critical findings addressed or explicitly documented.
  • Threat model updated where system boundaries changed.
  • Release notes and migration guides include security-impacting changes, new configuration options, roles/permissions, or secrets.

12. Metrics​

  • % PRs with security checklist completed
  • Mean time to remediate (MTTR) vulnerabilities
  • Dependency freshness (median age)
  • Test coverage of authZ code paths
  • Number and age of security exceptions

13. Example Artifacts (this release)​

  • SBOM: civitas-core-<ver>-sbom.json (CycloneDX)
  • Provenance: SLSA attestation in release assets
  • Signatures: Cosign signatures for images & archives
  • Docs:

14. Appendix​

  • Open Source Standards: dependency selection and licensing follow the OSS policy in Open Source Standards.
  • Crypto Parameters: According to TR 02102 family, JWT signing algorithms allowed
  • Third‑Party Components: each integration gets its own mini threat model and hardening notes.
  • Guidelines and further reading: OWASP ASVS (L2 focus), OWASP Top 10

14.1 Sensitivity levels​

  • Low
    • No change to attack surface
    • Internal refactor, test-only changes, or purely cosmetic/UI work
    • No sensitive data or trust boundaries touched
  • Medium
    • Modifies existing interfaces or logic exposed to authenticated users
    • Handles non-sensitive data flows or expands operator configuration surface
    • Introduces new dependencies without privileged execution
    • Moderate impact if misused, exploitable, or buggy
  • High
    • Introduces new external interfaces, APIs, or federation endpoints
    • Handles sensitive data (credentials, PII, secrets, tokens)
    • Affects authentication/authorization, cryptography, or secrets management
    • Expands trust boundaries (plugins, integrations, cross-instance comms)
    • Exploitation could compromise confidentiality, integrity, or availability of the system

14.2 TR-03187 Scope & Schutzlevel​

This SSDLC is designed to cover all requirements in BSI TR-03187 – Sicherheitsanforderungen an Urbane Datenplattformen that are assigned to the roles Entwickler and Lösungsanbieter for at least Schutzlevel 1, but always striving for the highest level we can reasonably support.

  • Schutzlevel: CIVITAS/CORE targets Schutzlevel 1 as default. Where individual deployments have different protection needs, operators MAY choose Schutzlevel 2/3 for their own processes, but the product’s security properties and defaults are implemented to meet Schutzlevel 1. If it is possible for us to support requirements from Schutzlevel 2/3 at a reasonable level of implementation effort, we MAY choose to do so.
  • Rollenabgrenzung:
    • CIVITAS/CORE team: fulfills developer and integrator (Entiwckler und Lösungsanbieter) requirements (software, documentation, supply chain, update process).
    • User operators (Kommunen, Rechenzentren, Dienstleister): fulfill operator (Betrieber) requirements (operation, monitoring, hardening, organisational measures).
  • The SSDLC is aligned with the TR-03187 building blocks Architektur, Authentifizierung/Autorisierung, Schnittstellen, Logging, Datenhaltung, IT-Sicherheitsorganisation and is intended to be used as part of an overall ISMS (e.g. IT-Grundschutz-basiert) on the operator side.

TODO documents and documentation:

  • Hardening & operations docs
  • Migration docs
  • Threat model
  • SRN template: (TODO: own document or integrate in the MR template?)